OPEN DOCUMENT FORMAT 


ODF ALLIANCE _ 

July 20, 2007 

Ms. Bethann Pepoli 
Acting CIO 

Information Technology Division 
Commonwealth of Massachusetts 
One Ashburton Place, Room 801 
Boston, MA 02108 

RE: ODF Alliance Comments on Draft ETRM v4.0 

Dear Ms. Pepoli, 

On behalf of the OpenDocument Format Alliance 1 (ODF A), I appreciate the opportunity to 
comment on the Enterprise Technical Reference Model (ETRM) v4.0 - Public Review Draft. 

The Alliance includes more than 400 member organizations in 52 countries dedicated to 
educating policy makers, IT administrators and the public on the benefits and opportunities of 
the OpenDocument Format (ODF). ODF helps ensure that government information, records 
and documents are accessible across platforms and applications, even as technologies change. 

Introduction 

The ODFA commends the Commonwealth of Massachusetts' leadership in 2004 to adopt an 
open standards policy 11 requiring that all future IT procurement be based on open standards 
whenever possible. Further, we commend the Commonwealth's leadership with ETRM v3.5 in 
2005 to identify ODF as the standard for all official documents the Commonwealth creates and 
saves. The decision to move to an open format was based on a fundamental public policy 
interest - that government documents belong to the people and should not be locked up in a 
proprietary format that restricts access to users of a particular technology or vendor, or 
prevents public access to those documents in the future because the software in which the 
document was created is obsolete, or the vendor goes out of business. 

With this critical decision, the Commonwealth brought worldwide attention to the problem of 
ensuring that our digital history is not lost to future generations, and it proposed a solution - 
ODF - that has been emulated worldwide. To date, eight national governments, three other 
regional/state governments, and more than 50 government agencies worldwide 111 have since 
recognized the benefits of open standards, like ODF, in terms of public access to information, 
ensuring technology neutrality and promoting choice. 
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Indeed, the ODFA strongly agrees with the ETRM framework to identify standards that 
support the Commonwealth's goal of building a service-oriented architecture which would both 
enable its IT components to interoperate seamlessly, and, importantly, encourage citizen¬ 
centric, user-friendly electronic interaction with the public. However, the ODFA strongly 
opposes the recent draft ETRM v.4.0 proposal to recognize Ecma-376 Office Open XML File 
Formats (OOXML) as an acceptable open format at this time. This proposal breaks with the 
core objectives of the 2004 open standards policy and the ETRM to ensure interoperability and 
foster better IT governance, while also improving the quality and accessibility of information 
and services. Please find below the following detailed comments and recommendations on 
behalf of the ODF Alliance: 

1. Acceptance of OOXML is a contradiction to the Commonwealth's open standards 
policy 

2. Acceptance of OOXML raises serious questions for people with disabilities, and 

3. Detailed recommendations to improve ETRM v.4.0 

1. The acceptance of OOXML is a contradiction to the Commonwealth's open standards 
policy and ETRM. 

The Commonwealth's open standards policy requires open standards to allow multiple vendors 
to compete directly based on the features and performance of their products, and to provide for 
an existing technology solution that is portable and that can be removed and replaced with that 
of another vendor with minimal effort and without major interruption. 

OOXML is in direct contradiction with these laudable objectives, and public access to vital 
records and information would be seriously compromised by the inclusion of OOXML under 
the ETRM. Until such time as OOXML has full, demonstrable multi-vendor support across 
multiple platforms, the Commonwealth should refrain from recommending its use by executive 
agencies, hollowing are the critical factors that currently prevent OOXML from being 
considered an “open standard.” 

• OOXML Is A Single-Vendor Format - To date, OOXML has been implemented in a 
single, proprietary product, Microsoft's Office 2007, meaning there will be no true 
choice for the Commonwealth and its citizens should OOXML be recommended under 
the ETRM. Moreover, OOXML's complexity, extraordinary length, technical 
omissions and single-vendor dependencies combine to make alternative 
implementations unattractive as well as legally and practically impossible. While two 
vendors have announced partial support (text documents only) for OOXML through the 
ODF- OOXML translator, this tool merely saves to OOXML, and, in its current state of 
development, would not be suitable in an office environment requiring collaboration on 
a document. There is still not an implementation for the Mac. 

• OOXML Is Not Interoperable - OOXML is either dependent upon, or optimized for, 
a catalog of Microsoft software applications and platforms and does not function fully 
with non-Microsoft software.— The practical effect of such dependencies is that the use 
of OOXML by Executive Agencies will require the purchase of licenses for Microsoft 
operating systems on both the desktop and the server as well as Microsoft Office 2007 
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at considerable cost to Commonwealth taxpayers. Platform dependencies of OOXML, 
which are features that can only be implemented or optimized for Windows and will 
break or not function the same way in non-Microsoft environments, include DevMode 
and GUID, among others. Application dependencies include VBA macros contained in 
OOXML documents that will not run when outside Microsoft applications, and an 
enumerated list of border art means that every application that wishes to fully comply 
with the OOXML must somehow license the use of those graphics. 1 

• OOXML Is Not Fully Published - In order to be implemented by other software 
vendors and developers, an open format needs to be fully published, yet OOXML 
contains numerous undocumented and unspecified features. To the extent that a format 
feature is only partially specified or not specified at all, other vendors' products will not 
be interoperable with it. Examples of partially or unspecified features include 
embedded macros and scripts. There is missing information from the specification 
document, for example, on how to do a autoSpaceLikeWord95 or 
useWord97LineBreakRules. Indeed, many elements designed into the OOXML formats 
but left undefined in the OOXML specification require behaviors upon document files 
that only Microsoft Office applications can provide. This makes data inaccessible and 
breaks work group productivity whenever alternative software is used. 

• OOXML Is Not Free of Patenting or Licensing Restrictions - The patent-protection 
pledge in Microsoft's Open Specification Promise only protects what is explicitly 
specified in the standard. There are numerous implied, referenced and undocumented 
facets and behaviors of the OOXML formats (see above) which, if implemented by 
another entity, would risk "intellectual property" (patent) violations against Microsoft 
software. 

• OOXML Is Not a Faithful Implementation of XML - The ETRM states that one of 
the most critical SO A decisions for the Commonwealth is the adoption of XML as the 
primary standard for data interoperability. It describes XML as “the lingua franca of 
application integration, facilitating application interoperability, regardless of platform 
or programming language,” and a cornerstone of the Commonwealth’s Service 
Oriented Architecture. Yet OOXML disregards sensible XML practices which serve to 
prevent accessing data across disparate systems. More than 10% of the examples 
mentioned in the proposed standard do not validate as XML.vi 

• OOXML Is Not Developed and Maintained In An Open Process - Despite being 
submitted to a formal standards body, control of OOXML ultimately rests with one 
organization. There is no guarantee that new OOXML features developed by Microsoft 
will be provided to Ecma, and experience has shown that the development of 
proprietary extensions will weaken a standard and make alternative implementations 
unattractive or impossible. 

2. Acceptance of OOXML raises serious questions for people with disabilities 

The release of ETRM v3.5 and the subsequent important accessibility concerns raised by the 
disability community with respect to office documents have raised worldwide consciousness of 
the impact of information technology decisions and standards on the lives of people with 
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disabilities. The high water mark set by ODF vl.l should not be allowed to recede with the 
acceptance of anything less from OOXML in ETRM v4.0. However, the acceptance of 
OOXML raises a number of important accessibility questions that should be addressed by the 
Commonwealth before it recognizes OOXML as an acceptable format, regardless of its 
openness. Particularly, the following points: 

• OOXML Fails to adequately support Web Content Accessibility Guidelines v.1.0 - 

According to a white paper authored by Microsoft 

r <http://openxmldeveloper.org/archive/2007/07/02/Accessibility_of_Qpen_XML.aspx 

> ) evaluating OOXML against the Web Content Accessibility Guidelines (WCAG) 
v.1.0, there are seven WCAG accessibility checkpoints that OOXML failed to support, 
and another four accessibility checkpoints that OOXML only partially supports. Some 
of these checkpoints represent significant accessibility issues - including several issues 
that OASIS ODF Accessibility subcommittee discovered in its public, peer-review of 
ODF vl.O and which were fixed in ODF vl.l. OOXML should be held to the same 
accessibility standards as ODF - the Commonwealth should not take a step backward in 
its IT support of employees with disabilities. 

• OOXML raises additional accessibility concerns that apply to office documents - 

Separate from the accessibility failings that Microsoft itself has noted in OOXML, 
there are a number of important accessibility concerns that apply to office documents 
not covered in an evaluation based on WCAG 1.0. These include the suitability of the 
document format for the creation of DAISY format digital talking books for people 
with print impairments, and the creation of Braille documents for the blind. The 
OASIS ODF Accessibility subcommittee explicitly addressed these questions in their 
review of ODF vl.O, and OASIS adopted additions to ODF vl.l expressly to support 
DAISY. Subsequent support of ODF vl.l in the leading Braille transcription 
application and review by their transcription engineers have validated ODF vl. 1 as an 
excellent basis for Braille production. The Commonwealth should be certain of the 
suitability of OOXML for DAISY and Braille document creation before accepting it as 
an acceptable open format in the ETRM 

• OOXML fails to meet the critical principle of involving the accessibility 
community in the development of standards - We have seen no information about 
whether the Ecma 376 standardization process involved disability experts and people 
with disabilities in its development - and especially whether this process was 
undertaken by a peer-review body of such individuals. Standards developed and 
deployed without a thoughtful accessibility review by accessibility experts and by 
people with disabilities too often has resulted in the erection of significant barriers to 
people with disabilities. The principle of involving people with disabilities was clearly 
articulated by the European Council eAccessibility Resolution of February 2003 
f http://ec.europa.eu/emplovment_social/news/2003/oct/eAccessibilitv_en.pdf) that 

people with disabilities should be empowered “to take more control over the 
development of the mechanisms for delivering eAccessibility", and "by support for 
their increased participation in standardisation bodies and technical committees.” 
ETRM v3.5 accepted ODF vl.l in part because of the input and peer review of experts 
in the disability community, and the input and peer review of individuals with 
disabilities who sat on the open ODF Accessibility subcommittee. ETRM v4.0 should 
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continue to uphold this core principle and insist that all standards accepted under the 
ETRM that impact people with disabilities must include people with disabilities in the 
development of those standards. 

• The cost of the expensive assistive technologies that are needed in order to work 
with the sole program that supports OOXML presents an unfair cost burden - 

While the Information Technology Division ETRM only has jurisdiction over internal 
Executive Branch documents, ITD should recognize the dimension of affordability in 
the choice of document formats, not only for the cost burden on government users, but 
also the burden placed on citizens and individuals who exchange documents with 
government. That burden is greatly magnified by the cost of the expensive assistive 
technologies that are needed in order to work with the sole program that supports 
OOXML - Microsoft Office - on the sole platform where such tools work - Microsoft 
Windows. The Commonwealth’s acceptance of OOXML as an acceptable document 
format could lead to a $1,500 expense - and the sole use of Microsoft Windows (at 
additional expense) - for blind inclusion to access this format. This is in sharp contrast 
with the ITD's policy in support of ODF, which can be fully utilized by blind citizens 
using a powerful and free screen reader that is well supported by the flagship open 
source ODF application on a free UNIX desktop. In fact, several free UNIX 
distributions available today already include this combination, and are presently in use 
by blind citizens in the Commonwealth. 

3. Recommendations for Technical Improvements to ETRM v4.0 

As articulated above, the ODFA strongly disagrees with the proposal to recognize OOXML as 

an acceptable open format at this time. Short of this change, following are recommendations 

for technical improvements that could be made to the draft ETRM v4.0 to ensure that it meets 

the interests of employees and citizens of the Commonwealth alike. 

(1) Expand definition of open formats to include the commonly accepted criteria 
that open formats must be “implemented by multiple interoperable applications 
on multiple, independent operating systems.” This change would ensure that the 
benefits of openness, including choice and interoperability, are achieved, consistent 
with the explicit requirements in the Commonwealth’s policy on open standards. 
Further, such a change would be consistent with definitions of many ODFA members, 
recent government policy documents , such as the final Interoperability Frameworks in 
Japan which prefers open standards and recognizes ODF as one) and many others (e.g., 
http://perens.com/OpenStandards/Definition.htnil and 

http ://www. cvber. law, harvard, edu/epolicv ) 

(2) Remove statement in the description of OOXML that “This XML-based 
document format was developed to ensure the highest levels of fidelity with legacy 
documents created in proprietary Microsoft Office binary document formats such 
as .doc, .xls, and .ppt.” This statement implies that a transition from proprietary 
Microsoft Office binary document formats - those currently in use by the 
Commonwealth - to OOXML would be the most seamless and logical. However, this 
assertion is completely without merit as it has not been verified by any standards 
organization or credible third party evaluation of conversion between OOXML and 
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binary formats. Further, OOXML does not fulfill its objective to provide for backward 
compatibility with previous binary formats of Office documents because the necessary 
mapping has not been provided for implementors to be able to develop applications to 
achieve backward compatibility. 

Additionally, for interoperability with legacy .doc, .xls and .ppt documents, it is 
important to consider not only the end user interactive editors, like MS Office, but also 
any other systems that read or modify documents in these formats. We note that the 
journals Science and Nature are rejecting OOXML documents because their publishing 
system relies on a third party application which does not support OOXML (see 
http://education.zdnet.com/7pM086). One can not assume that the move to OOXML is 
transparent and painless merely because Office 2007 supports both formats, particularly 
given the absence that disallows the development of third party software that can also 
interoperate seamlessly. 

(3) Amend guidelines to specify that “The Open XM L format may be used for text 
documents (.docx) provided that they can be faithfully exchanged, with fidelity, 
with ODF. The Open XM L format may be used for spreadsheets (.xlsx), and 
presentations (.pptx) once these have been implemented by more than one 
application and provided that these implementations can provide faithful 
exchanges with ODF,” This amendment would recognize that OOXML as 
implemented in .docx (text documents) is the only implementation that has any 
conversion capabilities with ODF and legacy binary document formats, and even 
focused on text documents there are still conversion issues and a dearth of choice. 

(4) Update the ETRM to report current state of OOXML and ODF 
implementations. Reword the section to make clear that only for text documents has 
OOXML been implemented via a translator by another vendor. Language should read: 
“Based on information publicly available regarding implementations, the OOXML 
format for text documents (.docx) is currently supported by Microsoft Office 2007, 
OpenOfiice Novell Edition and NeoOffice 2.1. Corel has announced OOXML support 
for WordPerfect 2007 to be available in its next release.” 

As for ODF, the language can be updated to read: “One of the principal objectives as 
specified in the OASIS ODF Technical Committee charter is to have as many 
implementations as possible and, indeed, multiple implementations of ODF exist today. 
Currently OpenOfiice.org, StarOffice, KOffice, Lotus Notes, AbiWord, Google Docs 
and Spreadsheets, Zoho Writer, AjaxWriter and other applications work with ODF 
documents. In addition, there are a number of translator software solutions that enable 
other office suites, such as Microsoft Office, to translate documents to and from 
OpenDocument Format for text documents, spreadsheets and presentations. Among 
these plug-ins is Sun Microsystem's ODF Plug-in 1.0 for Microsoft Office, which is 
currently being deployed within the Commonwealth.” 

(5) Update the ETRM Information Domain to incorporate a requirement that 
acceptable formats must be developed with involvement of people with disabilities 
and disability experts. As articulated above, standards developed and deployed 
without a thorough accessibility review by accessibility experts and people with 
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disabilities too often has resulted in the erection of significant barriers to people with 
disabilities. Therefore, the addition of this requirement would ensure better support for 
people with disabilities going forward. 

(6) In the proposed definition of OOXML, remove statement that the format has 
been approved by Ecma “as an open standard.” On the contrary, Ecma has 
approved the specification only as a standard, but not an “open standard” or “open 
format.” As you know, OOXML is currently being considered by the International 
Organization for Standardization (ISO) as an internationally recognized standard, but 
no conclusion has yet been reached. 

Conclusion 

Competing products is a good thing; competing standards will add costs, uncertainty and 
confusion to the Commonwealth and its citizens alike. While a software vendor is certainly 
free to adopt its own document format whose features and functionality are closely linked to its 
own platform and applications, the Commonwealth should not choose such a format for use by 
its executive agencies that will compromise the objective of ensuring long-term public access 
to vital records and information, and the preservation of the Commonwealth's digital history. 

Again, thank you for the opportunity to comment on the proposed revisions to the ETRM. If 
you have any questions regarding these comments, please do not hesitate to contact me at 
mmarcich@odfalliance.org or 202-789-4450. 

Sincerely, 

Marino Marcich 
Managing Director 
ODF Alliance 

i http://www.odfalliance.org 

ii http://www.mass.gov/Aitd/docs/policies_standards/openstandards.pdf 

iii http://www.odfalliance.org/resources/GlobalViewODFPolicv.pdf 

iv http://www.odfalliance.org/resources/Achieving_Openness.pdf : see pps 

v Clip-art should not be defined in the file format since clip-art licensing is not uniform or 
standard on every platform and this creates another operating system and application 
dependency 

http://www.grokdoc.net/index.php/EOOXML_Objections_Clearinghouse#Inappropriate_user- 

interface_specifications:_Clip_Arf ) and http://lnxwalt.wordpress.com/2007/Q4/Q6/to-the- 
members-of-the-california-state-assembly/ 

vi 

http://www.odfalliance.org/resources/The%20Technical%20Case%20Against%2000XML.pd 
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